docs(rfc): add RFC 000.0002 Flutter RFC Review & Decision Process - #4
docs(rfc): add RFC 000.0002 Flutter RFC Review & Decision Process#4jtmcdole wants to merge 4 commits into
Conversation
|
TODO: make sure to have wording around "no pocket vetos" |
Piinks
left a comment
Piinks
left a comment
There was a problem hiding this comment.
Big fan.
Note to follow up on:
- Current design doc page: https://github.com/flutter/flutter/blob/master/docs/contributing/Design-Documents.md
- Current design doc template: flutter.dev/go/template
- Breaking changes docs: https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#handling-breaking-changes
- Mentions getting fcontrib accounts for design docs: https://github.com/flutter/flutter/blob/master/docs/contributing/Contributor-access.md
| * **Subsystem Tech Leads (TLs)**: The technical leads overseeing the domains touched by the proposal. | ||
| * Flutter TLs **SHOULD** know about designs touching their systems. | ||
| * Formal sign-off requires approval from the primary Subsystem TL (or an appointed member) and affected secondary domain TLs (or their appointed members). | ||
| * **Flutter TLs Group**: The collective body of Flutter Tech Leads (`flutter-tls`). Serves as the first-line escalation path for deadlocks. |
There was a problem hiding this comment.
We could make flutter-tls a GitHub team that is taggable, assignable for reviews?
There was a problem hiding this comment.
Caveat: the members of this team would be visible.
There was a problem hiding this comment.
But not their email - just their github account? That seems "fine" given you could figure that out from PRs, comments, and social media?
| Note over Author,Forum: Stage 2: Socialization & Feedback | ||
| Author->>Repo: Async review via GitHub PR comments | ||
| opt Needs Broader Visibility / Contentious | ||
| Author->>Forum: Book 45-min Dash Forum slot (>=7 days lead time) |
There was a problem hiding this comment.
Dash Forum is only currently mentioned in the design doc page I linked above. It is only accessible by members of the org (right now, flutter-hackers), folks not in flutter-hackers (or in the future, on the contributor ladder) cannot attend or present. do we want to change this? How do we manage acces?
There was a problem hiding this comment.
If someone writes an RFC that is complex enough that it gets through some TLs - I think we'd be OK inviting said person to present at the forum. The real question is: What if they cannot or will not present? I would vote for the Shepherd to step in and make a decision on presenting or not.
Thoughts?
There was a problem hiding this comment.
I think we know that the forum for this will almost certainly be the Dash Forum, but does this RFC need to be opinionated about that? Could the RFC just specify that it is some appropriate 45 minute meeting, and the shepherd is responsible for putting it on the right meeting calendar (right now just the Dash Forum)?
| 1. **Required Approvals**: | ||
| * The proposal **MUST** receive a formal GitHub PR **Approve** from the Shepherd. | ||
| * The proposal **MUST** receive a formal GitHub PR **Approve** from at least one Subsystem TL representing each secondary subsystem listed under `tags:`. | ||
| 2. **Sequential Number Allocation (Pre-Merge Requirement)**: |
There was a problem hiding this comment.
I imagine folks will deviate from this in all sorts of ways. Any linting we could do?
There was a problem hiding this comment.
I think we'll write a github action.
| * **Two-Pagers**: Projects with broader scope that consume other teams' APIs or subsystems in new ways without altering their public API/ABI contracts. These **SHOULD** be handled via GitHub Discussions or lightweight design docs with informal alignment between team TLs. Authors **MAY** optionally author these as lightweight RFCs if they seek broader community feedback, but a formal RFC is not required unless system boundaries or contracts change. | ||
|
|
||
| ### 2. MUST Require an RFC (Full Design Docs) | ||
| A proposal **MUST** go through the RFC process if it meets any of the following criteria: |
There was a problem hiding this comment.
Are there any changes to infrastructure or Flutter contributor workflows that would need an RFC?
There was a problem hiding this comment.
Yes. E.g. external embedders would be a GREAT rfc.
| * **Subsystem Tech Leads (TLs)**: The technical leads overseeing the domains touched by the proposal. | ||
| * Flutter TLs **SHOULD** know about designs touching their systems. | ||
| * Formal sign-off requires approval from the primary Subsystem TL (or an appointed member) and affected secondary domain TLs (or their appointed members). | ||
| * **Flutter TLs Group**: The collective body of Flutter Tech Leads (`flutter-tls`). Serves as the first-line escalation path for deadlocks. |
Establish the review, socialization, and decision-making lifecycle for Flutter Requests for Comments (RFCs) to disentangle high-level architectural decision-making from code review across Flutter-owned repositories. Key elements established: - Self-contained threshold criteria distinguishing One-Pagers, Two-Pagers, and mandatory Full Design Docs / RFCs. - Clear roles for Author, Shepherd, Subsystem Tech Leads (TLs), the Flutter TLs group, and Flutter Leads. - 3-stage review lifecycle: Proposal & Draft PR (AAA.000), Socialization & The Dash Forum, and Asynchronous Approvals. - Optional Final Comment Period (FCP) for cooling off without stalling uncontroversial consensus. - Pre-merge sequential numbering constraint guaranteeing that AAA.000 never lands in main and rejected designs never burn sequential numbers. - Federated escalation path to the Flutter TLs group for deadlock resolution. Fixes: #3
This is a non-blocking note right? As in "land this, and then we update all these other places"? |
jtmcdole
changed the title
3 participants
Establish the review, socialization, and decision-making lifecycle for
Flutter Requests for Comments (RFCs) to disentangle high-level
architectural decision-making from code review across Flutter-owned
repositories.
Key elements established:
and mandatory Full Design Docs / RFCs.
TLs group, and Flutter Leads.
& The Dash Forum, and Asynchronous Approvals.
uncontroversial consensus.
never lands in main and rejected designs never burn sequential numbers.
Fixes: #3
Stack created with GitHub Stacks CLI • Give Feedback 💬